The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In computer networks, network elements such as routers, switches and others are responsible for moving packetized information within the network and directing the information to end station devices. Information arriving at or sent from a network element is communicated using one or more ports. A port may have a direct physical association with a chassis connector that terminates a network cable. Additionally or alternatively, port(s) may have a logical association with a connector.
The role that a port plays in a network element, or the identity of the neighbor of the port, can dictate a specific configuration for that port. For example, the configuration of a switch port that is connected to a PC might be very different than the configuration of the same port when connected to a business-critical server. As another hypothetical example, the configuration of the port might be different if a WAN link to a distant router is attached as opposed to a lab router connected via a LAN. To configure the port correctly, network administrators need to know the role of a port or the identity of the device to which it is attached.
At present, acquiring such knowledge is a manual process. The manual process is time-consuming and requires manual record-keeping. Further, if an end station device is changed, a port connected to that device may require re-configuration to account for differences in the new end station device. Currently, this requires manual intervention by an administrator, which is costly.
The Cisco Networking Services (CNS) solution from Cisco Systems, Inc. can discover information about the physical setup of modular routers including what kind of ports are present; however, CNS does not determine information about which devices are connected to the ports that it has discovered.
In one related approach, an “Auto-Configuration” mechanism uses a Trivial File Transfer Protocol (TFTP) server to load a configuration to a network switch. The Cisco Intelligent Engine 2100 (IE 2100) uses a similar approach, but transfers configuration information using HTTP. However, both of these approaches impose configuration challenges relating to proper configuration of the associated servers, and impose higher costs for servers on their users. Further, while the IE2100 can dynamically create a configuration for a device based on the types of ports discovered, it cannot do so based on what devices are connected to the ports.
In another approach, a network switch or router stores one or more role-based macro configuration templates. Each template is associated with a LAN switch role, such as “access,” “distribution,” or “core.” The templates apply particular configuration commands to interfaces of the switch depending on the associated role of the switch port. However, this approach does not discover devices that are connected to ports of the switch in the network, and does not determine what role is played by devices that are connected to ports of the switch. The network administrator is required to use a separate manual process to perform any such discovery and role determination, with the associated burden of keeping appropriate records and responding to changes manually as the changes occur. The approach also does not automatically apply a different configuration to each port based on determining the role of a connected device.
In another approach, RADIUS attribute-value pairs may be used to provision services on sessions based on the identity of a user; in this context, a session is defined by information specifying a port and a user for a period of time. For example, a user dials in to an access router, PPP authentication is performed via RADIUS, and the RADIUS reply contains configuration parameters for a port that are applied by the access router. When the connection terminates, a default configuration is restored to the port. However, this approach does not establish a port configuration based on the type of device coupled to the port or the role played by the port with respect to the device.
Thus, there is a need in this field for an improved automated way to configure ports of network elements based on discovering what devices are connected to the ports and what roles the ports or devices have in the network.